home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1203.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.5 KB  |  50 lines
  1. Thus wrote: Rob Raisch
  2. >> > 1) Kerberos should normally be invisible to users; there should be a
  3. >> > TGT whenever the user is logged in.
  4. >> Yes, for a single realm.  The problem is that with the Web you are reading
  5. >> documents from all over (many possible realms).  Are you going to require
  6. >> that the user kinit in a shell window for each document at a different
  7. >> site (possibly having to exit the browser each time for line-mode browsers
  8. >> with no job control)?
  9. >
  10. >    Well, this is the problem.  The solution is not to use something like
  11. >Kerberos to authenticate a user to a publisher, since Kerberos does not scale 
  12. >to
  13. >the level we are going to need on the Global Internet.
  14. >
  15. > [much more stuff by many people about kerberos deleted]
  16.  
  17. The biggest problem I have with scaling kerberos to this level is the
  18. amount to which trust also must be scaled.  A high-level
  19. authentication server which is responsible for providing
  20. authentication for a lot of other servers would be responsible for a
  21. lot of commercial traffic, and thus it's not difficult to imagine
  22. circumstances in which it would be worth a very large amount of money
  23. to compromise it.  What agency/organization do you trust to be so free
  24. of possible corruption and security breaches to guard these high-level
  25. authentication servers that could govern hundreds of millions of
  26. dollars in commercial traffic?
  27.  
  28. Someone correct me if I'm wrong, but I don't believe kerberos allows
  29. for non-deniability of orgin, which is exactly what is needed for this
  30. kind of an application (i.e. publisher A needs to prove that request I
  31. must have been sent from user B, and could not have been forged by
  32. publisher A, even with the cooperation of authentication authority Q.
  33. Otherwise they can do the electronic equivalent to forging your
  34. signature on credit-card slips, and there's no way to prove whether
  35. user B or publisher A is lying when they disclaim wrongdoing.)
  36.  
  37. For this kind of thing, I still think PEM is the way to go, as it will
  38. be made interoperable with MIME (which HTTP already uses, a nontrivial
  39. win) quite soon.  (Unless, of course, things like electronic cash
  40. actually start being available and used.)  The only serious question
  41. is whether the better stopgap is to use kerberos for the time being or
  42. to use symmetric-key PEM until asymmetric becomes useful (which may
  43. not be until the patents run out in a few years, sigh.)
  44.  
  45. (By the way, this is also going to the newsgroup.  I generally am
  46. hesitant to post to the mailing list because I'm really sick of bounce
  47. messages.)
  48.  
  49. - Marc
  50.